步骤里有失败项，测试运行却显示已经结束；用例这次执行通过了，工作项状态仍停在审核中。看到这些情况，先别急着改结果。Polarion里的步骤判定、测试记录结果和测试运行状态分别记录不同内容，用例工作项还有自己的流程。需要查清页面显示的是哪一项，再判断数据有没有写错，以及项目规则是否真正限制了状态转换。

评审后改了几条需求，再比较两份基线，正文修改能看到，状态变化却没有出现；另一个条目明明还在文档里，比较时又像被删掉了。遇到这类情况，先保留两侧的修订号。基线名称、文档路径、过滤条件和显示选项都需要核对，单凭差异页上的红绿标记，还不足以判断某项修改是否进入了基线。

需求和测试用例都已录入，追踪矩阵里却仍有空白，未必是关联没有保存。链接角色、查询范围和查看的版本不同，都可能影响显示。Polarion通过工作项之间的结构化链接建立追踪，核对时既要检查记录本身，也要检查矩阵的统计条件。把需求编号写进用例描述，通常不能代替这种关联。

给工作项加了“待评审”状态，用户却找不到提交入口；负责人已经填写，系统仍提示条件不满足。这类问题往往需要回到具体动作检查。Polarion如何配置工作项状态转换Polarion工作流条件设置后状态无法流转如何排查，可以围绕一条实际路径展开：由开发人员把“处理中”的工作项提交到“待评审”，提交前必须填写负责人，并满足项目规定的检查条件。

修改需求后，历史记录里的内容看着不对，先记下需求编号，再确认自己打开的是哪个版本。Polarion会记录单条需求工作项的修改，也会记录承载需求的LiveDoc修订版；文档基线和项目基线则对应不同的保存范围。一位同事查看工作项最新内容，另一位打开上次交付的基线，两人看到的文字可能不同。

在Polarion中执行一批测试用例，通常要先创建测试运行（Test Run）。创建后如果只有部分用例找不到执行入口，先记下这些用例的编号：它们可能没有进入本次运行，也可能关联了不同的文档版本。下面按创建、排查和复查的顺序操作。界面名称以所用版本为准。

工作项换了负责人、状态也更新了，相关人员却没有收到邮件。排查前先记下工作项编号、操作时间和预期收件人，再确认规则监听的事件与接收对象。下面以工作项邮件通知为例，介绍项目规则的设置方法和检查顺序。

在Polarion里，工作项明明存在，列表里却找不到，可以先从查询范围和筛选条件查起。下面以配置一条查询为例，再用已知编号的工作项核对遗漏原因。操作时以当前版本的界面标签为准；项目自定义字段的名称可能与示例不同。

Polarion项目仪表板一般通过LiveReport Page和Widget组合展示项目进度、需求状态、缺陷数量、测试执行情况等数据。仪表板页面本身只是展示载体，真正决定组件显示结果的是查询范围、筛选条件、页面参数和当前用户权限。遇到Work Item已经修改，仪表板里的数字或列表却没变化时，可以先检查组件到底在查哪些数据，再判断是页面配置没有更新，还是当前账号读取不到对应对象。

Polarion的LiveDoc把普通文档编辑和Work Item管理放在同一个页面里，可以直接维护需求、测试用例、缺陷以及它们之间的关联。创建文档后，Work Item显示多少内容并不是固定的，文档自己的展示配置、当前过滤条件、用户权限和Work Item状态都会影响页面结果。遇到标题能看到但字段缺失，或者某些Work Item整条不见时，要先分清是展示配置问题，还是对象已经被过滤、移除或权限限制。